It is not uncommon to create machines where the data source is not local. However, often the data access requires authentication separate from the user's login authentication to provide data at login and to maintain it as accessible for the duration of user. This presents some challenges to making a user's home directory accessible in a secure manner. Permitting a user to login to a remote machine may be done in various ways. Generally speaking, applications run on a server computing system (e.g., host computing system) and a terminal, also known as a thin client or X terminal, handles input and output from and to the user of the application. The terminal may be a client computing device, such as a desktop computer, a laptop computer, or other computing devices. Thin clients may be low-powered, lack a hard disk, etc. An interface can be presented on the client computing system, as if it were accessed locally. The interface can be used by a user to remotely log in to a networked computer hosting the services. In this computing environment, users may have home directories which are used across multiple machines. In one conventional approach, the home directory can be made accessible to a user by copying the home directory to the local system that the user is logged into.
Another approach is to use Network File System (NFS) protocol to share disks between different machines. In particular, data storage disks contain files stored in filesystems within a standardized directory structure. New disks are added to the filesystem by attaching or mounting, the directories of their filesystem to a directory of an already existing filesystem. This in effect makes the new hard disk transparently appear to be a subdirectory of the filesystem to which it is attached. NFS was developed to allow a computing system to access directories on remote computers by mounting them on a local filesystem as if they were a local disk. The systems administrator on the NFS server has to define the directories that need to be activated, or exported, for access by the NFS clients, and administrators on the clients need to define both the NFS server and the subset of its exported directories to use. Data access over a network always introduced a variety of challenges, especially if the operation is intended to be transparent to the user, as is the case of NFS. The virtual filesystem (VFS) interface is the mechanism used by NFS to transparently and automatically redirect all access to NFS-mounted files to the remote server. This is done in such a way that files on the remote NFS server appear to the user to be no different than those on a local disk. VFS also translates these requests to match the actual filesystem format on the NFS server's disks. This allows the NFS server to be not only a completely different operating system, but also use different naming schemes for files with different file attribute types. The drawback of using NFS is that it is insecure.
Another approach is to use a sshfs command to mount a home directory. Secure Shell protocol (SSH) Filesytem (SSHFS) is a filesystem client that mounts and interacts with directories and files located on a remote server or workstation. The client interacts with the remote file system via the SSH file Transfer Protocol (SFTP), a network protocol providing file access, file transfer, and file management functionality over any reliable data stream. SFTP provides secure file transfer and a secure remote file system. Whilst SFTP clients may transfer files and directories, the related file system may not be mounted locally using SFTP alone. For example, Filesystem in Userspace (FUSE), which is a loadable kernel module that lets non-privileged users create their own filesystems without editing kernel code, may be used. When using FUSE, the filesystem code is run in the userspace while the FUSE module provides a bridge to the actual kernel interfaces. FUSE is particular useful for writing virtual file systems because, unlike traditional file systems that essentially save data to and retrieve data from disk, virtual filesystems do not actually store data themselves. They act as a view or translation of an existing file system or storage device. Using SSHFS, a locally-mounted file system may be treated in the same way as other volumes (such as CDs, DVDs, USB flash drives and shared disks).
Conventionally, in order to do an auto sshfs mount, a user creates a set of ssh keys that do not require a passcode. Then the administrator can access those keys in autofs or at boot time if they just want the mount to persist. The problem with storing ssh keys is this means a set of keys actually have to be available to the administrator. This is not practical in an environment where the users are managed remotely, such as in a Kerberos environment. For example, in some cases, the administrator may not even be aware when a new user is added or such. The other problem is this conventional method creates a central access for other machines on the network. Anyone who gains access to those keys can effectively breach any machine on the network using those same home directories. Another problem with the conventional method is that a shell script to mount the directory will cause the directory to persist until manually unmounted. Over time on a busy machine, various home directories would be mounted on that machine. This is a huge amount of network connections to maintain within the network, and of course again creates a one-stop hacking location. Anyone gaining administrator access has access to the directories who have logged on anytime in the past. Another problems when using auto sshfs mount with FUSE, most FUSE daemons are not stable for very long term use and can freeze their mount. When a user tries to subsequently login in, the user will find that their mount is frozen, and hence their login is deadlocked.